…uite-success (#1241)

GitHub fires `check_suite.completed` once per workflow. When workflow A's
suite fails fast (e.g. the E2B template-rebuild on ucho/PR#176 — 38s) and
workflow B's suite is still running, the failure handler correctly defers
with "not all complete yet". When workflow B's suite eventually completes
with `conclusion=success`, only the success handler fires — and it
unconditionally dispatches `review`. That review is silently skipped at
worker time (`pollWaitForChecks` sees `allPassing=false`), and no later
event with `conclusion=failure` ever wakes the failure handler back up.
Net: `respond-to-ci` is permanently lost for that SHA.

Fix: in the success handler, after the author + base gates, query the
aggregate `getCheckSuiteStatus` and fork. When `allComplete && anyFailed`,
dispatch `respond-to-ci` (gated by its own trigger config + attempt limit)
instead of `review`. Otherwise, current behavior — dispatch review with
`waitForChecks: true` so the worker polls if checks are still in progress.

Single-source the dispatch envelope: extract `dispatchRespondToCi` plus
`fixAttempts` / `MAX_ATTEMPTS` / `resetFixAttempts` into a new shared
module `respond-to-ci-dispatch.ts`. Both handlers converge on it. The
failure handler keeps its early `gateTriggerEnabled` so disabled projects
don't burn GitHub API calls; the helper re-checks the same gate so the
success-handler fork is also guarded.

Tests: 5 new TDD cases on the success handler — failure conclusion,
timed_out conclusion, in-progress checks (defers to worker), all-passing
(review), and the "already-reviewed at HEAD with CI failure" case (CI
failure trumps prior approval). Adjusted the existing pre-existing
"getCheckSuiteStatus not called" assertions to match the new flow:
removed where the call now happens (post-base-gate), kept where the gate
short-circuits before it.

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>